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Testing for Compliance 
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Abstract — AMBA Compliance enables the developer of an IP 
component to demonstrate that the testing of the AMBA interface 
has achieved a pre-defined quality level. 

Index Terms — ARM, AMBA, Advanced Micro-controller Bus 
Architecture, AHB, AMBA High-speed Bus, APB, AMBA 
Peripheral Bus. 

i Introduction 

THE AMBA specification is an on-chip bus specification 
which is intended to allow the rapid building of System- 
on-Chip (SoC) devices by the integration of a number of 
different IP components. The AMBA specification enables this 
process by providing a standard interface, which allows the IP 
supplier to design and test the module without any knowledge 
of the system in to which the component will be finally 
integrated. 

In a given company/design house, IP components that are 
used to construct a SoC may be obtained from a number of 
different suppliers, including: i) Third party IP suppliers such 
as ARM, ii) other internal design departments, iii) the SoC 
design team itself, 

AMBA Compliance enables the supplier of an IP 
component to demonstrate that the testing of the interface has 
achieved a pre-defined quality level and this, in turn, gives the 
SoC integrator confidence that the component will function 
correctly when integrated in to the rest of the SoC design. 

II. Overview Of Compliance Testing 

AMBA Compliance Testing is performed using a simulation 
environment in which the IP component is exercised. The 
simulation environment also contains the following two 
elements: 

A. Protocol Checker 

Cycle by cycle checks to ensure that the device under test 
obeys the rules within the AMBA specification. The protocol 
checks are a fixed set of rules from the AMBA specification 
and a component must not violate any rules in order to claim 
AMBA compliance. There is no configuration of the protocol 
rules. An example of an AMBA AHB Master protocol rule is, 
*7/i the second cycle of a Split or Retry response the master 
must drive HTRANS to IDLE\ 

B. Coverage Monitor 

The coverage points are a list of various bus transactions that 
must be observed within the test environment before 
compliance can be claimed. The aim of coverage points is to 
ensure that the tests have sufficiently exercised the component 
under test before compliance can be claimed. An example of a 
coverage point is, "The bus slave must be accessed by a read 



transfer followed immediately by a write transfer to the same 
address". 

The advantage of using coverage points, compared to a 
standard pre-defined sequence of bus transactions, is that it 
allows for the fact that a particular IP component may require 
a specific sequence of transactions- in order to fully exercise 
the bus interface. 

m. Compliance Test Environment 

Two typical environments are shown in the diagrams below. 
In the first environment Fig. 1 the device under test is 
connected to a standard AMBA testbench, which reads the 
stimulus generation and response checking information from a 
User Defined Test Sequence file. 

It is important to note that the Protocol Checker and the 
Coverage Monitor do not automatically check the integrity of 
the data transferred during compliance tests. The user should 
ensure that the device under test (DUT) operates correctly 
during a 'compliance run'. When configured as in Fig.l, the 
compliance test environment aids in the operational testing of 
the DUT by supporting 'data checking commands' in the User 
Defined Test Sequence input file. 
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Fig. 1 . fOn completion of test, reports test cases that have not been observed. 
$ During test, reports protocol violations. In this environment, the user 
supplies: 'Configuration*, "User Defined Test Sequence* and an RTL 
implementation of "Device Under Test*. 

In the second case, a system simulation environment is used 
to provide the stimulus and response checking for the device 
under test. This environment still retains the Coverage 
Monitor and the Protocol Checker. This is illustrated in Fig. 2 
below: 
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Fig. 2. Inside dotted boundary is a System Simulation Environment. In this 
Passive Mode environment, the user supplies: 'Configuration', 'Svstem 
Simulation Environment' and an RTL implementation of 'Device Under 
Test 1 . 

IV. Claiming AMB A Compliance 

AMBA Compliance is a self-certification process. The IP 
supplier is responsible for performing the tests for compliance 
and making a suitable declaration, as described below: 
The Declaration of AMBA Compliance must include: a) 
AMBA Specification revision number, b) Compliance 
configuration, c) Explanation of any compliance coverage 
points hot tested. 

ARM has developed an AMBA Compliance Toolkit (ACT) 
for the sole purpose of enabling an IP supplier to generate and 
ship an AMBA IP compliance solution. 

.An IP Supplier who claims AMBA compliance for a 
particular IP component is able, using the ACT toolkit, to 
supply a testbench environment including any required 
vectors, enabling the User to repeat the Compliance test. Any 
User who has access to the IP component may request this. 

Note however that the ACT supplied to repeat the 
compliance test, is locked per IP component, and cannot be 
configured therefore to test generic IP. 

V. Compliance Test Configuration 

There is no configuration of the Protocol Rules, and an IP 
component must not violate any of the AMBA Protocol Rules 
in order to claim compliance. 

However, the Coverage Points may be configured to allow 
for the fact that certain AMBA modules will not utilise all the 
features of the bus. It is important to note that the allowable 
configurations for a module are defined so that all modules 
will always work together correctly. 

As a basic rule 'an AMBA component must be able to 
accept all possible input combinations, but it does not have to 
generate all possible output combinations'. 

To illustrate this, a bus master that has input signals for 
Transfer Ready, Transfer Response and Bus Grant must be 
able to deal with all possible combinations of these inputs. 
However, it is not required to generate all possible output 
combinations, so it is only required to generate the types of 
burst and transfer sizes that are appropriate to its operation. 



It should be noted that turning off certain coverage points 
would enable additional protocol checks. For example, if a 
bus master compliance check is configured for a bus master 
which does not support 4-beat wrapping bursts this 
configuration option will have the effect of removing the 
coverage points to observe various types of 4-beat wrapping 
burst. It will however enable an additional check to ensure that 
the master never performs this type of transfer. 

A slave must also be capable of accepting all possible 
inputs and must deal correctly with all the different 
combinations of transfers. However, it is acceptable to build 
slaves, which do not utilise all the transfer information that is 
available on the bus. A typical example of this would be a 
slave, which does not use the burst information. To simplify 
the compliance testing of such slaves, if the slave does not 
have certain signals as inputs then the coverage points related 
to the different combinations of that input could be omitted. 

VI. ACT Features 

In summary so far then, we have established that a given 
ACT configuration can operate either as in Fig. 1 or in a 
System Simulation Environment as illustrated in Fig. 2 (the 
Protocol Checker and the Coverage Monitor components 
being common to both scenarios). The above two ACT 
operating modes are termed as Active mode, and Passive 
mode respectively. 

In order to specify these configurations, ARM has also 
implemented a powerful yet simple "Configuration APF, 
which not only describes what signal names a DUT has, but 
also the capabilities of the DUT itself for coverage 
configuration. A further feature of the Configuration API is to * 
enable access to generic parameters such as: input and output 
file specifications, bus-width, endianess, debug and error 
reporting. .Only one Configuration API input file is required 
for multiple ACT configurations; this is especially useful for 
Passive Mode; although multiple configurations are feasible 
for Active Mode, only single DUT example scenarios are 
currently provided with the ACT package. 

A. Active Mode Features 

An Active Mode ACT configuration greatly reduces the 
burden of having to generate a point-solution testbench for 
each user DUT; in fact the ACT itself generates all the 
necessary AMBA fabric' around the DUT in order to allow 
user supplied stimulus to be driven onto the DUT during the 
process of compliance testing. 

RTL 'trickbox' examples are provided for interfacing with 
the DUT. The trickbox allows non-AMBA signals of the DUT 
to be controlled and observed. The trickbox has a 32-bit output 
port and a 32-bit input port, as well as standard AHB/APB 
slave interface to control the trickbox. The AHB/APB. 
interface means that the trickbox can be instantiated in the 
testbench and is controlled by using test vectors, which access 
the trickbox, rather than the DUT. 

Active mode configurations will support the following 
devices: AHB Master, AHB Slave, APB Master (Bridge), 
APB Slave, Arbiter and Decoder. 
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In order to drive Masters or supply Slave responses, Active 
Mode also provides the facility for reading stimulus from 
vector files specified in the Configuration API. The format of 
these stimulus files has been specifically designed such that 
they can either be hand-written, or more conveniently auto- 
generated using languages such as Perl or C. 

Depending on the configuration/type of DUT, certain 
additional facilities may also be enabled from the ACT. In the 
case of the AHB Master configuration, a behavioural memory- 
slave device is generated that has both memory initialisation 
file, and itself generates a memory-dump file of the same 
format. This configuration can be observed in Fig. 3 below: 
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Fig. 3. The master DUT accesses the bus as if it were communicating to a 
slave device. However the environment created around it drives back directed 
responses. The trickbox component is muxed in with the slave response 
signals to enable additional behaviour. 
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Fig. 4. The slave DUT accesses the bus as if it were responding to a master 
device. However the environment created around it drives directed responses. 
The trickbox component is also muxed in with the slave response signals to 
enable additional behaviour. For example in AHB mode, the trickbox may 
provide waited responses as another slave device. 



B. Passive Mode Features 

Aimed primarily at an in-system test environment, passive 
mode effectively disables the concept of ACT 'auto-generated 
AMBA fabric', and stimulus-driving capabilities, as is 
otherwise available in Active Mode. As mentioned above, the 
same Configuration API file is used for specifying details 
about the DUT itself. In this mode however, any Active Mode 
specific configuration options are ignored. 



Passive mode is also ideal for verifying legacy designs, as 
the user does not need to isolate the DUT into an Active Mode 
testbench for compliance testing. It must be noted however 
that achieving full coverage is possibly more challenging in 
Passive Mode, if the source of stimulus to the DUT has a 
limited transaction or scenario generating capability. A more 
likely scenario would be to ensure that the DUT did not 
generate any AMBA protocol violations over the course of a 
sequence of test runs. 

In either mode of operation, a coverage report is generated for 
optional viewing at the end of a run. This is in the form of a 
GUI that displays both the completed and outstanding 
compliance coverage goals associated with the DUT and its 
particular capabilities configuration. It is from this data that an 
"AMBA Compliance Certificate' can be generated. 

vn. Configuration API Detail 

The ability to specify multiple ACT configurations from a 
single configuration file is very useful. Conventional methods 
rely on a deep knowledge of the signal mappings and 
capabilities of the DUT, which ultimately lead to 'point 
solution* scenarios and hence reduced testbench re-usability. 
Even if a specific toolkit is" developed for test, there is an 
implicit degree of re-configuration and 'tweaking' to get a 
particular DUT to sit comfortably within the test environment. 
ARM has addressed this issue using a three-step solution. 

A. Thin RTL D UT interface module - Active Mode Only 
When the DUT is submitted for testing in ACT Active 

Mode, it is declared and instantiated in a simple RTL top-level 
module. This module 'interfaces' to a full ACT AMBA test 
environment, which is dynamically created at simulation time 
(see part C. below), depending on the ACT configuration file 
supplied. The interface module also provides optional clock 
and reset signals, along with an optional trickbox interface and 
associated signal muxing between RTL and the ACT AMBA 
test environment itself. 

B. User Configuration file 

For each ACT operational mode (one of: AHB_M ASTER, 
AHB_SLAVE, APBJV1ASTER, APB_SLAVE, ARBITER, 
DECODER, either in Active Mode or Passive Mode), 
example User Configuration files are provided. 

The remaining entries in each section provide the following 
configuration information to the ACT: i) DUT Name and 
optional ID, ii) HDL Path/Level of hierarchy of the DUT in 
the design iii) DUT signal map e.g. HCLK-HCLKsys, or 
HCLK=~/top/HCLK to override ii) above, iii) General 
testbench parameters e.g. ENDIANESS=LI 1 7 LE, 
ERRORSTOP= YES, VERBOSITY-ERRORS jONLY. iv) 
Coverage configuration e.g. DIRECTION -NO _WRITE for 
devices that are read-only. 

C Configuration API Engine 

As part of the ACT initialization sequence, the User 



Configuration file is read in and parsed. If no configuration 
errors are found (e.g. missing signal definitions, invalid input 
files, bad parameters), the Configuration API Engine 
dynamically instantiates the required ACT test components. 
For example in AHB Master Active Mode, Arbiter, Decoder , 
Default Master, and Slave models are generated and 
automatically interfaced to the DUT. In AHB Slave Active 
Mode, a Decoder and a Master model are generated. 

VIII. Protocol Checking Detail 

The basic principle of protocol checking an AMBA bus is to 
employ a sequence of checks for ensuring that the AMBA bus 
protocol is observed during transactions, which comprise of a 
number of bursts, of individual transfers. The current 
implementation of ACT uses temporal expressions to allow 
simulation events to trigger heuristics that describe these 
protocol checks. Another approach that could be adopted is 
that • of Property Checking, however this particular 
methodology is still currently under evaluation. An extract 
from ARMs property checking tool evaluation programme is 
given in part B. of this section. 

A. Temporal Expressions 

A temporal expression is a combination of events and 
temporal operators that describes behavior. A temporal 
expression captures temporal relationships between events, 
values of fields, variables, or other items during a test. 

Due to the large and varying number of temporal expressions 
used in the ACT, only a brief concept view of how these 
constructs are used is described here. 
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Fig. 5. Legend for Temporals Graphics 



The Verisity Specman™ 'e' language was chosen amongst 
other reasons for its rich temporal language implementation 
As an example, the following AMBA AHB sequence 
evaluation illustrates the monitoring of hgrant events with 
respect to the HTRANS signal being set to IDLE (an 
htrans. idle event) . 

With reference to Fig.6, the hclk event is the sampling event 
for the two sequences involving the hgrant and htrans. idle 
events. The hclk event itself is emitted at the rise of the HCLK 
signal. 

The {@hgrant;@htrans.idle} sequence starts evaluating each 
time hgrant occurs at hclk. When htrans. idle is sampled one 
hclk after hgrant , the sequence succeeds. 

The {@hgrant;[l];@htrans.idle} sequence also starts 
evaluating at the first hgrant occurrence at hclk, and shifts at 
the next occurrence of hclk due to the "followed by 1 cycle" 
clause ([1]). On the third occurrence of hclk, the sequence 
succeeds. Note however that the temporal expression does not 
evaluate after the 5 th cycle, because of the absence of the 
htrans.idle event 
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Hg. 6. Example graphical notation to represent evaluation of temporal 
sequences. Note that some events relate directly to signal values, other events 
are defined from a combination of signal states sampled at the reference event 
- the rising edge of HCLK in the case of AMBA AHB. 

In this way, protocol errors can typically be defined by using 
events such as those described above to capture a condition 
where a particular rule is not being observed. These events can 
be used to either build further event sequences, or they can be 
logically combined to generate assertion statements. A typical 
form for an ACT protocol rule may be: 

expect <rule> is {<temporal-expression>} @hclk; 
B. Property checking techniques 

ARM is currently evaluating Property Checkers, EDA tools 
based on a formal mathematical techniques. Formal property 
checking involves writing a property that closely matches a 
system requirement, and then proving exhaustively that the 
property holds on the design. The exhaustive nature of this 
technique means that it can find bugs that are not covered by 
functional simulations. 

A particular property checking EDA tool (that is also 
currently under evaluation at ARM), was used to implement 
the AMBA AHB protocol rules, which were written as formal 
properties and proven on an ARM core Bus Interface Unit 
(BIU), which was in turn connected to an AMBA bus. 
Property checkers work best at the block levels, with blocks 
under 100k gates being ideal (the BIU is less than 20k gates). 

The property language for the tool being used has a Verilog 
syntax with just a few temporal constructs that allow you to set 
or check signals at particular clock cycles (relative to some 
starting clock cycle). An example of such a property is a 
requirement for the HTRANS signal output to be IDLE or 
NON-SEQUENTIAL if the AHB master is not granted. The 
property was written to match the following timing diagram: 
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Fig. 7. Timing diagram to represent the HGR ANT/HTR AN S property. 



Times t and t+1 in the timing diagram in Fig. 7 represent clock 
cycles. The dotted value is an assumption and the following 
IDLE/NSEQ part is a proof obligation. The timing diagram is 
saying that // the HGRANT signal is low in one clock cycle 
(time t), then the HTRANS signal must be IDLE or NSEQ in 
the following clock cycle. The proof is exhaustive, so time t 
can be any arbitrary clock cycle. You can think of property 
checking in terms of a simulation metaphor, imagine sliding 
the timing diagram over an exhaustive simulation - whenever 
the assumptions hold the obligations must hold. 

If your property passes then your RTL will always satisfy 
this requirement. If the property fails, then the property 
checker outputs a short 'VCD waveform' file for debugging. 

The debug waveform in this case highlighted a fail where 
the HGRANT signal was low at time t but the HTRANS 
signal was SEQ at t+1. The property .failing was the correct 
result but there was no bug in the RTL - the property itself 
was incomplete. It turned out after further examination of the 
AMBA AHB Specification Rev.2, that if the AHB Master is 
waiting (HREADY signal input low) then HTRANS should be 
maintained. The property was corrected to match the following 
timing diagram: 
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each burst type (SINGLE, INCR, WRAP4, INCR4, WRAP8, 
INCR8, WRAP16, INCRI6), has different slave response types 
observed for both read and write bursts. 

From the User Coverage Configuration, the ACT coverage 
engine decides on what features to cover, and what protocol 
rule(s) need to be added/ignored during testing. 

At the end of a test execution run, all coverage information 
is collated into a GUI that enables the user to identify how 
much of the required coverage space a DUT has explored. 

Coverage goals are plotted as Red/Amber/Green 
histograms, and should sufficient coverage goals be reached, a 
certificate is produced that qualifies the DUT as AMBA 
compliant. Where the DUT configuration specifies that certain 
features are not supported, these are noted as exceptions on the 
compliance certificate. Fig. 9 shows a typical coverage GUI 
for an AHB Slave DUT. 




Fig. 9. Example coverage GUI output for an AHB Slave DUT. Each aspect of 
coverage can be viewed, along with coverage 'holes' that have not yet been 
observed using the current test environment/stimulus file. 



Fig. 8. Timing diagram to qualify the HGRANT/HTRANS property with the 
HREADY signal. 



Note that this property says that if the master is not granted 
and is not waiting, then the HTRANS signal must be IDLE or 
NSEQ in the following clock cycle. The corrected property 
was proven, in just a few seconds of CPU processing time. 

On a final note, one of the interesting challenges of property 
checking is to develop the ability to easily identify valid 
starting states. In one evaluation, it was noted that a particular 
protocol violation was caused only because one of the 
exhaustive starting conditions was identified as 'impossible to 
reach 1 . 

IX. Coverage Monitor Detail 

Coverage is the process of observing specific sequences of 
AMBA bus activity. Again, the Verisity Specman™ tool 
enables the ACT to achieve this through the definition of 
'coverage groups'. A coverage group is a program 
structure/object member that contains a list of data items for 
which data is collected over time. 

A useful feature of the Specman™ tool is the ability to 
perform cross-coverage; this allows observation of interaction 
between coverage data items. An AMBA AHB Master 
e-xampte-of cross -cove rage usage would be to ensure that for 
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